Alright @GregorShear take a look at the most recent commit. A few worthy call-outs:

This leaves all existing authorization checks alone

Every existing authorization call-site stays exactly as it was. evaluate_names_authorization, is_authorized, authorized_prefixes, and friends all continue to receive models::Capability::Read/Write/Admin from their callers, return the same errors, and behave identically against current grants. The only thing that changes underneath is what those calls do internally: each legacy capability now lowers into a CapabilitySet (an EnumSet<authz::Capability> of fine-grained bits) via bits_for_legacy, and the BFS evaluates over bits. So the call site says Capability::Admin and what actually gets checked is the Admin bundle's bit set — but no caller has to know that yet.

This means the commit doesn't migrate any enforcement site to fine-grained bits. That's intentional: a future PR can deliberately design new bits and move specific gates onto them (e.g., CreateInviteLink for invite link operations) without conflating that work with the model introduction here.

Capability::None enables bundles-only grants

We added None = 0 to the legacy Capability enum, mapped onto the renamed none value of the DB grant_capability enum (formerly the x_00 placeholder, which already sorted below read). It exists for one reason: to allow a grant whose authorization comes entirely from the new bundles array column, with no legacy capability at all. A grant like capability: none, bundles: [billing] confers exactly the billing bits and nothing else.

Authorization is multi-path union, not any-path

The previous is_authorized() for legacy capabilities used "any one path satisfies" semantics. With the unified BFS, both legacy and bit-shaped queries go through the same algorithm (multi-path bit union), and bits_for_legacy lowers the legacy input to a bit-shaped question. For current grants (bundles=[]), the two rules return identical answers, so the existing snapshot test passes unchanged.

They diverge once bundle-bearing grants exist. The reason is the algebra: Bundle::Admin is defined as Editor | TeamAdmin | Billing. Once Admin is the union of those bit sets, asking is_authorized(_, Admin) is asking "does the user's accumulated bit set cover Editor's ∪ TeamAdmin's ∪ Billing's bits?" Any-path evaluation answers a different question, "did a single grant happen to carry all of those bits at once," which the model has stopped using as a primitive.

The deeper point: the end state isn't "check that the user has Admin's bits at the call site," it's "the call site checks only the specific bits the operation requires." create_invite_link will eventually ask for CreateInviteLink, not for Admin. Once enforcement is bit-shaped at every gate, Bundle::Admin becomes a storage and UI affordance for how humans grant capabilities in administrative-role-sized chunks, not an evaluation predicate. Multi-path union is the evaluation rule that survives this transition.

Naming

Capability is the right name for the fine-grained bit enum. In Rust we can lean into that and have both enums named Capability, namespaced under their respective modules: models::Capability for the legacy read/write/admin enum, models::authz::Capability for the bits. They never collide at use sites because we can fully qualify them.

Type names in GraphQL are a single flat namespace though, so I ended up keeping the OrthogonalCapability name for the bit enum on the GraphQL side, leaving the legacy Capability GraphQL type unchanged for the deployed UI.

The deployed UI's CreateInviteLink mutation references the legacy Capability GraphQL type by name ($capability: Capability!), so we can't rename it in the schema without coordinated UI work. We can rename it back to just Capability once that mutation is updated and the legacy enum is removed entirely.